Method of allowing multiple, hardware embedded configurations to be recognized by an operating system

ABSTRACT

A communications system for enabling extension of an internal common bus architecture (CBA) segment of a first root physical device to an internal CBA bus segment of one or more remote external physical device includes the first root physical device having a first serial communications interface module in the root device coupled between said internal CBA bus segment and an input and output port of the root device for serializing bus transactions from the first device to the output port of the root device and deserializing data received from at the input port to the internal CBA bus segment of the first device. The remote external physical device includes a second serial communications interface module coupled between the internal CBA bus segment and an input and output port of the remote device for serializing bus transactions from the remote device to the output port of the remote device and deserializing data received at the input port to the internal CBA bus segment of said remote device. The modules are coupled to each other by an external cabling. An enumerator in the root device obtains knowledge of the remote hardware module and accompanying register set by abstracting these details and automatically configuring the remote module in the system.

FIELD OF INVENTION

[0001] This invention relates to a serial, low pin count communicationsinterface that enables the extension of an internal Common BusArchitecture (CBA) bus segment to one or more external physical devicesand more particularly to a method of allowing multiple, hardwareembedded configurations to be recognized by an Operating System in anindependent manner.

BACKGROUND OF INVENTION

[0002] The communication to and from both home and office is undergoinga change to provide both cable and DSL broadband access. It is highlydesirable to provide a common computer/software/peripheral platformarchitecture across cable, DSL, IEEE 802.11, IP phone and voicegateways. A communications processor architecture includes a 32-bit MIPSprocessor, a switched bus architecture, a distributed DMA architecture,optimized memory interface, programmable memory management and writeback or write through cache write policy. The software platform for theservices includes device drivers (USB, PCI, Ethernet, HDLC, Timers,802.11 etc.), RTOS support (VxWorks, Linux, Nucleus etc.), networkingsoftware (ATM, TCP/IP, bridging, routing, filtering etc.), networkmanagement (SNMP, web servers/stacks), PC drivers, and robust APIs withclearly defined software layers for customers to add value. Acommunications chip for all of these markets becomes costly. TexasInstruments Inc. built a product that has two DSPs for voice, manyinterfaces, a mixed signal processor, RAM, a MAC, a completesegmentation re-assembly (SAR) engine for ATM, HM interface, a broadbandinterface, memory interface and a VGA. The result is a product that has256 pins and the chip becomes costly. This is also not very expandablebecause any expansion peripherals must be placed on the memory bus,which consumes memory bandwidth that is critical to the operation speedof the CPU. This also means that access to the peripheral is in theasynchronous cycle, which is slow as compared to DRAM. A 16-bit buscould be added with 32 pins but that is costly and would have a limitedmemory range. Many developers for products in these areas do not want topay for such a costly chip with excess functionality. We have had todisable features on the chip but the customer still has to pay forfeatures not used.

[0003] It is highly desirable to provide platforms for market segmentswherein the main function is functionally integrated and an expansioncapability is provided via a low cost, software compatiblecommunications link.

[0004] Texas Instruments Incorporated provides for this by providing aserial, low pin count communications interface that enables theextension of an internal Common Bus Architecture (CBA) bus segment toone or more external physical devices. This is known as VLYNQ and itaccomplishes this function by serializing bus transactions in onedevice, transferring the serialized transaction between devices via aVLYNQ port, and de-serializing the transaction in the external device.Multiple VLYNQ modules may be included on a single device such thatVLYNQ devices are effectively daisy chained.

[0005] Referring to FIG. 1 there is illustrated a serial (i.e. low pincount) communications interface (VLYNQ) that enables the extension of aninternal CBA (labeled VBUSP) bus segment to one or more externalphysical devices. VLYNQ accomplishes this function by serializing bustransactions in one device, transferring the serialized transactionbetween devices via a VLYNQ port, and de-serializing the transaction inthe external devices. VLYNQ is a 3,5,7 or 9-pin serial interface for1,2,3 or 4 bit parallel (serial but four bit wide) interface that allowsone to connect peripherals that previously could not be directlyconnected to a communications processor. The devices have an internalbus (VBUS). VLYNQ is a serial interface that connects the internal busof one device to an internal VBUS of another device. The internal VLYNQaccomplishes this function by serializing bus transactions in onedevice, transferring the serialized transaction between devices via aVLYNQ port, and de-serializing the transaction in the external device.

[0006] As illustrated in FIG. 1 the host communication processor 11includes an internal VBUS (a virtual bus) 11 a and a VLYNQ interfacemodule 13 connected by a serial cable 12 to a peripheral such as a TexasInstruments Inc. C55x Voice DSP 15 that also contains a VLYNQ interfacemodule 17 connected to VBUS 15 a of DSP 15. The VBUS or virtual bus isinternal to a semiconductor chip or device and provides thecommunications between modules on the chip or device using the chip ordevice standard protocols. The transmit pins on the first device 13connect to the receive pins on the second device 17. Request packets,response packets, and flow information are all multiplexed and sentacross the same physical pins. The above described connection betweenprocessor 11 and DSP 15 is a VLYNQ host-to-peripheral connection. Apeer-to-peer connection is also provided. This enables the extension ofan internal common bus architecture bus segment to one or more externalphysical devices. In FIG. 1 the first peripheral device (C55x Voice DSP)15 includes a second VLYNQ interface module 19 connected to the internalVBUS 15 a that is coupled by serial cable 14 to VLYNQ interface 20 at asecond voice DSP 21 for a peer-to-peer connection. The second voice DSP21 can be daisy chained to other DSPs or other peripherals via VLYNQinterface 23 and another cable.

[0007] An example of an application enabled by VLYNQ is a low costderived voice application, allowing one or more C55x DSP devices toconnect to an a Texas Instruments Inc. Avalanche Broadband Controllerover 3-pin serial interfaces. For more information of VLYNQ, refer toapplication Ser. No. 10/382,679 filed Mar. 6, 2003 entitled“Communications Interface”. This application is incorporated herein byreference.

[0008] Successfully connecting VLYNQ devices requires an in-depthknowledge of the hardware module and accompanying register set. It istherefore highly desirable to provide a method to aid in connecting thedevices.

SUMMARY OF THE INVENTION

[0009] In accordance with one embodiment of the present invention, anin-depth knowledge of the hardware module and accompanying register setis provided by abstracting these details and automatically configuringthe module in the system.

[0010] In accordance with an embodiment of the present invention amethod of allowing multiple, hardware embedded configurations to berecognized by an operating system in a root device comprises the stepsof recognizing and utilizing multiple embedded hardware configurationsin remote devices and making the configurations recognizable by anoperating system in an independent manner.

[0011] In accordance with an embodiment of the present invention anenumerator discovers all remote devices and creates address andinterrupt maps between remote devices and a root device.

[0012] In accordance with an embodiment of the present invention anenumerator reads a remote device identification register and locatesassociated device configuration file and then determines if the remotedevice has more than one interface module and if there is more than oneinterface module, recursively performing the previous steps until theend of the interface chain is reached.

[0013] In accordance with an embodiment of the present invention, acommunication system for enabling extension of an internal common busarchitecture (CBA) bus segment of a first root device to an internal CBAbus segment of a second device includes a module in the first device anda module in the second device and an external cable between thesemodules. The first root device includes an enumerator for automaticallyconfiguring for said second device module or more modules and/orexternal devices to be added to the system by a recursive discovery andconfiguration algorithm.

DESCRIPTION OF DRAWINGS

[0014]FIG. 1 is a block diagram of a host to peer and peer-to-peerserial interface connection according to one embodiment of the presentinvention.

[0015]FIG. 2 illustrates a method of allowing multiple, hardwareembedded configurations to be recognized by an Operating System in anindependent manner.

[0016]FIG. 3 illustrates the recursive algorithm used to configure VLYNQsystems.

DESCRIPTION OF PREFERRED EMBODIMENTS

[0017] VLYNQ is a serial, low pin count communication interface thatenables the extension of an internal Common Bus Architecture (CBA) bussegment to one or more external physical devices. VLYNQ accomplishesthis function by serializing bus transactions in one device,transferring the serialized transaction between devices via a VLYNQport, and de-serializing the transaction in the external device.

[0018] Referring to FIG. 2 there is shown the placement of a VLYNQenumerator 33 in the system 30. The “root” device (typically thecommunication processor) 31 is the single device that executes the VLYNQenumerator software. The examples of Puma or Sangam are given. It mustcontain at least one VLYNQ module (VLYNQ 0 (root)) 35.

[0019] Throughout this document, references are made to VLYNQ “gateways”and “portals”. The definition of a VLYNQ gateway is a VLYNQ module on aremote device that is the first one encountered when traversing out fromthe root device. Each device, therefore, has a single VLYNQ gatewaymodule. All other VLYNQ modules on each remote device are termed“portals”.

[0020] Several references are made to VLYNQ “branches”. A branch isdefined as all of the remote VLYNQ devices connected to a single rootVLYNQ module. This includes the directly connected device and anydaisy-chained devices connected from that point.

[0021] Successfully utilizing VLYNQ would normally require an in-depthknowledge of the hardware module and accompanying register set. Thepurpose of the VLYNQ enumerator is to abstract these details from thehigher-level software developers, freeing them to focus on applications.

[0022] The VLYNQ enumerator software 33 automatically configures eachVLYNQ in the system 30, creating a unified view of the system from thesoftware perspective. Developers need little or no knowledge about VLYNQhardware. The enumerator 33 operation is designed to be executed duringsystem boot, and requires no intervention on the part of the user. Theonly required inputs are properly formatted device configuration filesfor each VLYNQ device in the system. The format of these files isspecified in later in the specification under Device Information Files.The output of the enumerator 33 is an output file that contains addressmaps and interrupt information for each device (37 and 38) and VLYNQmodule discovered in the system 30. This file is discussed in moredetail later in The Output File.

[0023] The heart of the VLYNQ enumerator 33 is a recursive discovery andconfiguration algorithm. It discovers all remote VLYNQ devices like 37and 38 and creates address and interrupt maps from remote devices backto the root device. The VLYNQ module has flexible, built-in facilitiesfor address translation and interrupt forwarding. Based on theidentities of the discovered VLYNQ devices (and their associated deviceinformation files), the enumerator 33 configures each VLYNQ and puts theresults in an output file of the file system. For the example of FIG. 2it is the file system 31 a of the communications processor (root).

[0024] Remote devices are identified using VLYNQ's chip versionregister. The enumerator 33 is able to read the remote chip versionregister to identify remote devices and determine which deviceinformation file should be accessed. The table that follows lists thedevice ID's that have currently been assigned: List of Device ID'sDevice ID Avalanche 1 0x0001 Avalanche-D 0x0002 Avalanche “Taos” 0x0003Avalanche “Puma” 0x0004 Avalanche “Sangam” 0x0005 Voice DSP “VDSP”0x0006 Avalanche “Titan” 0x0007

[0025] Each “pass” of the VLYNQ enumerator 33 configures a single branchof the system. A branch in this case is defined as all VLYNQ devicesconnected to a single VLYNQ module on the root device. The softwarereads the root device configuration file to determine how many VLYNQmodules are on the root device. For each root module, the recursivealgorithm is executed (this is one “pass” of the enumerator).

[0026]FIG. 3 depicts the operation of the recursive algorithm. In short,the algorithm traverses the VLYNQ chain until it reaches the end device,which has no more VLYNQ modules or connections. Peripherals andinterrupts on the end device are then mapped, and the algorithm returnsthe sum of all the address space that was mapped. This return value isnecessary to properly configure the size of the VLYNQ portal.

[0027] In the enumerator algorithm, starting with a VLYNQ module on theroot device, it determines if there is a link (Step 1). If there is alink, the enumerator 33 reads the remote device identification registerand locates the associated device configuration file (Step 2). It thendetermines if the remote device has more than one VLYNQ. If there ismore than one VLYNQ, the enumerator 33 recursively performs the abovesteps until the end of the VLYNQ chain is reached (Steps 3-7). Theenumerator 33 determines that the VLYNQ chain is ended if a discovereddevice has only one VLYNQ module (Step 3), or if there is no link on allVLYNQ portals of a remote device. As the enumerator is working towardreaching the end of the chain, it also creates address mappings to theVLYNQ modules that it finds along the way (Step 4). This gives theenumerator 33 the information that it needs to revisit the VLYNQ moduleslater in order to create mappings for the remote peripherals. Once theenumerator reaches the end of a VLYNQ chain (Step 7 and 8), it createsmappings for the peripherals on the end device (Step 9). The returntotal size of all remote peripheral maps is sent to be recomputed thememory maps based on return value at Step 10. At this point, therecursive algorithm returns, which effectively moves the control back tothe previous VLYNQ device in the chain. It then determines if there isanother local VLYNQ and if so goes onto the next VLYNQ and traverses itto the end of its chain, as before. Eventually, the program flow willreturn to the root device (Step 8), which means the enumerator hascompleted all tasks for the given branch, and returns.

[0028] The recursive nature of the algorithm allows this software tofunction properly on arbitrarily large VLYNQ systems. There are nolimitations on the total number of VLYNQ devices or on per device VLYNQmultiplicity. However, VLYNQ hardware has some limitations such as thetotal amount of possible mapped space per branch (currently 64 MB), andthe total amount of interrupts available per branch (32). Theselimitations are discussed further under Limitations and Notes.

[0029] Device Information Files

[0030] Format and Development of Device Files

[0031] This section describes the format and use of device informationfiles. These files must contain information relating to the address map,interrupt map, and peripheral communication requirements (reversemapping) for the device.

[0032] Below is a summary of the format used for device into files, anda simple example: Device Information File Format (<device>.con) Vlynq(id= vlynq<n>,base = <phys base addr>, portal_size = <size>,control = <physregister addr>,control_size = <regs size>) <peripheral> (id =<peripheral>, base = <phys addr>, size = <size>,[VLMapped = <0,1>],[int_line = <a;b;c...h>, [int_type = <0, 1>;<0,1>,...<0,1>,int_pol =<0,1>; <0,1>,...<0,1>]],[map_to = <per1;per2..per4>, [map_to_offset =<offset1; offset2...offset4>, map_to_size = <size1,size2...size4>]])

EXAMPLE

[0033] #VLYNQ entries vlynq(id = vlynq0, base = 0x4000000, portal_size =0x4000000, control = 0x08611800, control_size = 0x100) vlynq(id =vlynq1,base = 0x8000000,portal_size = 0x4000000, control = 0x08611900,control_size = 0x100) # Peripheral entries perA(id = Peripheral A, base= 0x0b002500,size = 0x1000, VLMapped = 1,int_line = 6;10, int_type =1;0,int_pol = 0;1) perB(id = Peripheral B, base = 0x0c140000,size =0x100, VLMapped = 1,int_line = 8, map_to = sar;sdram, map_to_offset =0;0x10000, map_to_size = 0x1000;0xC000)

[0034] Each entry in the file must contain an “id” parameter to identifythe peripheral. VLYNQ entries must contain the base address and portalsize, as well as the register address and size. This information can befound in the associated device specification. Peripheral entries mustcontain only a base address and size, but have several optionalparameters.

[0035] Optional parameters are explained below:

[0036] Optional Peripheral Parameters

[0037] The VLMapped parameter is used to designate whether or not theperipheral will be included in the interrupt and memory map. If an entryof “VLMapped=0” is made in a peripheral entry, this peripheral isskipped by the enumerator. If VLMapped is set to anything else (orexcluded altogether), the enumerator will attempt to map it.

[0038] The int_line (and int_type, int_pol) parameter is used to specifywhich interrupt lines the peripheral uses on the VLYNQ device. One mayspecify up to 8 interrupts per device. This is a limitation of currentVLYNQ hardware, which only has 8 interrupt input lines as of the date ofthis specification. Multiple interrupts are supported for a singleperipheral, by creating an entry with a semi-colon delimited interruptlist, as in “int_line=1;2;3;4”.

[0039] The int_type and int_pol parameters may be used alongsideint_line to specify the interrupt type and polarity. For int_type, avalue of 0 specifies a level-sensitive interrupt, while a value of 1 isreserved for pulsed interrupts. Int_pol may be set to 0 (active high) or1 (active low).

[0040] The map_to (and map_to_offset, map_to_size) parameter is used tomap the peripheral directly to a memory region on the root device. Themap_to entry should be filled in directly with a semi-colon delimitedlist of regions to map to (i.e. map_to =sar;sdram). The enumerator willread the root device information file looking for the sar and sdramentries, in this example. Ensure that these entries exist in the rootdevice file. In the output file, the enumerator will replace the text“sar” and “sdram” with the mapped addresses to each of the regions.

[0041] The map_to_offset and map_to_size fields (optional) may be usedto specify an offset from the base address of the root peripheral, andthe size to map. If not used, the offset is assumed to be zero, and thesize will be set to the entire size of the requested root memory region.

[0042] An example of the use of the map_to parameter is the VDSP device,which for some application needs to access the SAR (Segmentation andReassembly) module on the root device.

[0043] In general, all of the information necessary to generate a deviceinformation file is available in the specification for the device. Forthe most efficient usage of VLYNQ resources, list all vlynq entries inthe file in the order of base address, starting with 0. Do the same forall peripheral entries. All address entries in device information filesshould use the physical address found in the associated memory map forthe device. Also, each interrupt line entry should give the number ofthe VLYNQ interrupt line used for that peripheral-this informationshould be available in the device specification.

[0044] The Output File

[0045] Output Format and File API

[0046] The following describes the output file and specifies softwareinterface for accessing the file.

[0047] When the enumerator algorithm has completed, all of the mappingsare collected and output to the output file. This file contains all ofthe information contained in the root file (options.conf), concatenatedwith any new entries that correspond to remote peripherals that havebeen discovered on VLYNQ devices. From the perspective of the softwaredeveloper, remote peripherals can be treated in exactly the same manneras local peripherals. An example output file is given below:

[0048] Example Output File (output.con) <contents of options.conf> ...... <concatenated output from enumerator follows> vlynq(if =Vlinq0,locator = 1.0,regs_size=0x100, regs_base=0xa0001180,int= 1)vdsp(id = vdsp,locator = 1.0,base = 0xa4002000,size = 0x1000, int =2:3,map_to = 0xa400000, map_to_size = 0x1000)

[0049] In the example given above, one remote device was discovered,with one vlynq and one vdsp peripheral. The locator parameter may beignored (it is useful to the enumerator development team as debuginformation in the case of failure). One will find that the baseaddresses given in the device information file have been altered and arenow valid virtual addresses. One will also notice that the interruptvalues have been remapped and may now contain a different interruptnumber. Finally, for any “map_to” entries that were specified in remotedevice information files, the name of the root peripheral region tomap_to has been replaced with a virtual address that is valid for thatperipheral. In the example, assuming that the VDSP device informationfile contained parameter entries “map_to=sar, map_to_size=0×1000”, thevdsp may now reach the SAR in the root device by accessing memory region0×a400000-0×a401000. Getting Data from the Output File A simple API hasbeen developed in order to extract information from the output file.Output File API /* *Returns a pointer into the file, at the “index'th”location of “device_name” *found in the file. Use index = 1 to get apointer to the first instance of *device_name in the file. Pass NULL inthe device_name in order to receive a *pointer to the index'th entry ofthe file. The return value is NULL if the *device_name is not found orEOF is encountered. /* char*get_device_info(int index, char device_name)/* *Pass the return value from above in the “info_ptr” parameter, andthis function returns *the string value specified by “parm”. The returnvalue is NULL if the specified *parameter cannot be found on the givenline. /* char*get_device_parm(char *info_ptr, char *parm) Example APIUsage: Int index = 1; Char*pszString, *pszBase, *pszSize; PszString =(char *)malloc(20); PszBase = (char *)malloc(20); PszSize = (char*)malloc(20); PszString = get_device_info(index,NULL); while(pszString!= NULL) { //process String information pszBase =get_device_parm(pszString, “Base”); pszSize = get_device_parm(pszString,“Size”) ... ... //get the next line of information from the filepszString = get_device_info(index, NULL); index++; }

[0050] Using this API, it is simple to extract any or all values fromthe output file. It is suggested that the software developer read all ofthe data in the output file into internal data structures in order toavoid accessing the file at run-time (see the above example).

[0051] Limitations and Notes

[0052] VLYNQ Address Maps

[0053] Each VLYNQ module can perform address translation for up to fourmapped regions. The enumerator software maps utilizes VLYNQ mapresources efficiently, sharing maps where possible. The algorithmcurrently uses the first map to map any VLYNQ portal registers on theremote device (if there is more than 1 VLYNQ device). If there aremultiple VLYNQs on a remote device, and their base addresses are notcontiguous, more that one VLYNQ map will be required. For the mostefficient operation, all VLYNQ register regions should be contiguous inthe memory map. If this requirement is met, a virtually unlimited numberof VLYNQ modules can be supported per device.

[0054] The second VLYNQ map is typically used to allow access to remotedevices that are even further “downstream”. This is only necessary ifthe remote device has more than one VLYNQ. Since VLYNQ portals are solarge (64 MB typically), it is impossible to map the entire size of aportal. Instead, assuming that VLYNQ portals have been allocatedcontiguously in the device memory map, one VLYNQ map is exhausted forevery two VLYNQ portals. The implication of this is that VLYNQ devicesmay have a maximum of 7 VLYNQ modules (assuming that the device does notalso have any peripherals to map).

[0055] After VLYNQ registers and portals have been mapped, any deviceperipherals may be mapped if any of the four maps remain, or ifperipheral regions happen to be contiguous with maps that have alreadybeen configured. Again, it is important that the device designer makeevery effort possible to map important peripherals and registerscontiguously, in order to allow the greatest possible flexibility forVLYNQ systems.

[0056] If VLYNQ map resources run out before all maps have beenconfigured, an error message will be generated, and some peripheralswill not be mapped and will not have an associated entry in the outputfile.

[0057] Interrupts

[0058] Each VLYNQ branch (each root VLYNQ module) may map up to 32remote interrupts. This limitation is imposed by the 32-bit size of theInterrupt Pending/Set register in VLYNQ. A further limitation of 8interrupts per VLYNQ device is imposed by the fact that each VLYNQmodule currently supports only 8 interrupt input lines.

[0059] Each VLYNQ module in the system consumes one interrupt for anyVLYNQ module interrupts that may occur. The interrupt value assigned toany VLYNQ or peripheral is written to the output file.

[0060] Interrupt Handling

[0061] Each root VLYNQ is wired to a single interrupt in the rootinterrupt controller. When one of the interrupts is asserted, the VLYNQInterrupt Status/Clear register must be read to determine whichinterrupt(s) have occurred. The software must then compare this value tothe mapped interrupt values that were read from the output file todetermine the source of the interrupt. The VLYNQ Interrupt Status/Clearregister may be found at the following address: (VLYNQ virtual baseaddress=0×10). Read this memory location to determine the interruptstatus. After servicing the interrupt, one should also clear theinterrupt. To clear an interrupt, write a 1 to any bit in the register.

[0062] Reverse Mapping

[0063] Remote devices may require a direct mapping to a peripheral ormemory region on the root device. This functionality can be used byadding the “map_to” parameter to peripherals in a device informationfile. Doing this consumes a single VLYNQ map in each portal VLYNQmodule, and consumes one or more maps in the root VLYNQ module. One maymap remote devices to a maximum of four non-contiguous address regionson the root device. If reverse maps are made to contiguous regions onthe root device, the only limitation is the 64 MB portal size.

[0064] While the invention has been described and shown with referenceto a preferred embodiment, it will be understood by those skilled in theart that various changes in form and detail may be made therein withoutdeparting from the spirit and scope of the invention.

1. In a communications system for enabling extension of an internalcommon bus architecture (CBA) segment of a first root physical device toan internal CBA bus segment of at least one second external physicaldevice comprising: said first root physical device having a first serialcommunications interface module in said first device coupled betweensaid internal CBA bus segment and an input and output port of said firstdevice for serializing bus transactions from said first device to saidoutput port of said first device and deserializing data received from atsaid input port to said internal CBA bus segment of said first device;said second external physical device including a second serialcommunications interface module in said second device coupled betweensaid internal CBA bus segment and an input and output port of saidsecond device for serializing bus transactions from said second deviceto said output port of said second device and deserializing datareceived at said input port to said internal CBA bus segment of saidsecond device; and an external serial cable coupled to said input andoutput ports of said first and second devices for transferring theserialized transactions between said first and second devices, theimprovement comprising: an enumerator in said first root device forautomatically configuring for said at least one second serialcommunications interface module added to the system.
 2. The system ofclaim 1 wherein said enumerator abstracts knowledge of the hardware ofsaid second external device and accompanying register set.
 3. The systemof claim 2 wherein said enumerator includes means for inputting properlyformatted device configuration files for each said second deviceattached in the system and provides an output file that contains addressmaps and interrupts information for each device and modules discoveredin the system.
 4. The system of claim 1 wherein said enumerator has arecursive discovery and configuration algorithm that discovers allremote devices and creates address and interrupt maps between saidremote devices and the root device.
 5. A communication system forenabling extension of an internal common bus architecture (CBA) bussegment of a first root device to an internal CBA bus segment of atleast one remote device comprising: a first interface module in saidfirst root device and a second interface module in said at least oneremote device and an external cable between these modules; said firstroot device includes an enumerator for automatically configuring forsaid remote device to be added to the system by a recursive discoveryand configuration algorithm.
 6. The system of claim 5 wherein saidremote device is daisy chained to a further remote device by a thirdinterface module and wherein said enumerator automatically configuresfor said further remote device to be added to the system by saidrecursive discovery and configuration algorithm.
 7. The system of claim6 wherein said enumerator reads said remote device identificationregister and locates associated device configuration file and thendetermines if the remote has more than one interface module and if thereis more than one interface module, the enumerator recursively performsthe above steps until the end of the interface chain is reached.
 8. Thesystem of claim 8 wherein as the enumerator is working toward reachingthe end of the chain, it also creates address mappings to the interfacemodules that it finds along the way to give the enumerator theinformation that it needs to revisit the interface modules later inorder to create mappings for the remote peripherals.
 9. The system ofclaim 8 wherein once the enumerator reaches the end of an interfacemodule chain, it creates mappings for the peripherals on the end deviceand the return total size of all remote peripheral maps is used tocompute the memory maps based on return value and the recursivealgorithm returns, which effectively moves the control back to theprevious interface module device in the chain and then determines ifthere is another local interface module and if so goes onto the nextinterface module and traverses it to the end of its chain.
 10. A methodof allowing multiple, hardware embedded configurations to be recognizedby an operating system in a root device comprising the steps of:recognizing and utilizing multiple embedded hardware configurations inremote devices and making said configurations recognizable by anoperating system in an independent manner.
 11. The method of claim 10wherein said recognizing step includes inputting properly formatteddevice configuration files for each device to be attached in the system.12. The method of claim 11 wherein said recognizing step includes anenumerator discovering all remote devices and creating address andinterrupt maps between said remote devices and the root device.
 13. Themethod of claim 12 wherein said recognizing step includes saidenumerator reading said remote device identification register andlocating associated device configuration file and then determining ifthe remote has more than one interface module and if there is more thanone interface module, recursively performing the previous steps untilthe end of the interface chain is reached.
 14. The method of claim 13wherein as the enumerator is working toward reaching the end of thechain, it also creates address mappings to the interface modules that itfinds along the way to give the enumerator the information that it needsto revisit the interface modules later in order to create mappings forthe remote peripherals.
 15. The method of claim 14 wherein once theenumerator reaches the end of an interface module chain, it createsmappings for the peripherals on the end device and the return total sizeof all remote peripheral maps is used to compute the memory maps basedon return value and the recursive algorithm returns, which effectivelymoves the control back to the previous interface module device in thechain and then determines if there is another local interface module andif so goes onto the next interface module and traverses it to the end ofits chain.
 16. The method of claim 12 wherein said enumerator isexecuted during system boot, and requires no intervention on the part ofthe user.